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ABSTRACT 


Virtual  Prototyping  provides  an  opportunity  for  control  engineers  to  observe  and 
evaluate  their  designs  in  a  ’’real  world”  setting  without  the  costs  or  risks  associated 
with  flight  test.  Designers  Workbench  is  a  computer  aided  design  tool  that  allows 
a  user  to  create,  view,  modify  and  animate  three-dimensional  databases.  These  may 
include  instruments,  avionics  displays  and  any  out-the-window  applications  such  as 
runways  or  terrain.  The  dynamic  behavior  of  specific  elements  can  be  observed  by 
linking  data  to  the  desired  element.  In  this  way  a  realtime  animation  of  the  simulation 
can  be  generated.  The  animation  provides  another  analysis  tool  for  the  designer,  by 
representing  data  in  a  more  intuitive  environment. 

Data  files  from  two  separate  controller  simulations  was  used.  Cockpit  instru¬ 
mentation  was  modelled  and  used  for  each  animation  to  monitor  the  aircraft  states. 
In  addition,  each  animation  had  an  out-the-window  perspective  to  view  the  aircraft 
model  as  it  flew  the  prescribed  trajectory. 
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I.  INTRODUCTION 


A.  BACKGROUND 

While  SIMULINK  and  SYSTEMBUILD  provide  powerful  capabilities  in  the 
design,  testing  and  analysis  of  dynamic,  non-linear  controllers,  they  are  very  limited  in 
their  abilities  to  provide  suitable  data  representation  for  conducting  an  actual  flight. 
The  UAV  project  currently  at  the  Naval  Postgraduate  School  (NPS)  plans  to  provide 
Over-the-Horizon  capabilities  to  a  battlefield  commander.  Virtual  prototyping  will 
be  able  to  provide  a  link  between  a  pilot  on  the  ground  and  the  UAV  out  of  visual 
range.  This  link  will  provide  real-time  feedback  of  the  aircraft  states  in  a  more 
intuitive  setting  than  two-  or  three-dimensional  plots. 

The  primary  goal  of  this  thesis  is  to  expand  on  previous  work  done  at  the  NPS 
Avionics  Lab  that  incorporated  a  new  software  package  with  the  current  simulation 
and  design  tools  already  being  used.  With  the  software,  a  user  is  able  to  create 
models  in  a  ’’virtual”  environment  and  generate  animations  of  these  models. 

For  future  simulations,  a  model  of  a  generic  cockpit  was  created,  and  the  process 
of  generating  an  animation  was  streamlined  to  provide  future  users  with  a  relatively 
quick  and  easy  handbook. 

B.  DESIGNER’S  WORKBENCH 

Designer’s  Workbench  (DWB)  is  a  computer  aided  design  tool  that  allows  users 
to  create,  view,  modify  and  animate  three- Dimensional  graphic  databases.  These 
may  include  any  combination  of  instruments  or  avionics  displays  for  in-the-cockpit 
views,  and  any  out-the-window  applications  such  as  runways  and  terrain. 
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Simulation  data  from  a  controller  can  be  linked  to  specific  elements  within  DWB 
to  define  the  dynamic  behavior  of  that  element.  In  this  way  an  animation  can  be 
generated.  This  visual  representation  can  be  used  as  a  more  intuitive  way  to  evaluate 
the  performance  of  the  flight  control  system. 

C.  CONTROLLER  SIMULATIONS 

Data  from  two  different  controller  simulations  was  used  for  demonstrating  the 
capabilities  of  DWB.  The  first  was  an  Auto-land  controller  for  an  F-14  Tomcat  de¬ 
signed  by  LCDR  Rob  Niewoehner  (  Ref.  6  ).  Glideslope  and  angle-of-attack  were 
controlled  with  power,  stabilators  and  dynamic  DLC.  The  animation  required  the  cre¬ 
ation  of  two  models  for  the  out-the-window  view:  an  aircraft  carrier  and  an  aircraft 
to  represent  the  Tomcat.  Cockpit  instrumentation  was  also  developed  to  monitor  the 
states  of  the  aircraft.  The  states  were  simulation  specific,  based  on  the  needs  of  the 
designer,  and  DWB  was  used  to  create  the  appropriate  instrumentation.  In  this  case, 
airspeed,  altitude,  vertical  velocity,  attitude  and  power  were  monitored.  A  generic 
instrument  to  visually  display  errors  in  commanded  altitude  versus  actual  altitude, 
was  also  created.  In  addition,  links  were  included  to  allow  the  user  to  interactively 
choose  from  a  number  of  eye-point  perspectives,  allowing  for  different  views  during 
the  animation. 

The  second  data  file  used  was  from  a  trajectory  controller  simulation  for  the  NFS 
UAV,  Bluebird,  designed  by  LT.  Eric  Hallberg  (  Ref.  4  ).  While  a  DWB  animation 
had  already  been  created  by  LCDR  Mark  Lagier,  (  Ref.  5)  the  file  was  modified 
to  include  the  generic  instrument  models  for  the  in-the- cockpit  view  and  included  a 
tail-following  eyepoint  perspective  along  with  the  interactive  eye-point  links.  Errors 
in  position  and  altitude  were  also  displayed. 
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1.  Auto-Land  Controller  for  the  F-14 


For  the  simulation,  the  aircraft  was  initialized  at  1200  feet  AGL  and  was 
commanded  to  descend  at  600  feet/min,  as  is  done  in  an  actual  approach.  No  dis¬ 
turbances  were  introduced.  The  data  file  was  cut  from  90  seconds  of  simulation  time 
to  40  seconds  to  improve  DWB  performance,  and  as  Figure  1.1  shows,  the  DWB 
animation  only  goes  through  a  400  foot  altitude  change. 
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2.  Trajectory  Tracking  Controller  for  a  UAV 

Figure  1.2  shows  the  figure-8  flight  path  that  the  UAV  was  commanded  to 
fiy,  climbing  to  an  altitude  of  300  feet,  and  returning  to  its  start  point  at  50  feet 
above  the  ground.  A  right  crosswind  was  introduced  at  the  start  as  a  disturbance 
that  the  controller  had  to  account  for  while  trying  to  track  the  commanded  flight 
path.  The  disturbance  was  removed  on  the  short  final  approach  to  the  field,  again  to 
evaluate  the  performance  of  the  controller.  Figure  1.3  shows  the  errors  between  the 
commanded  and  actual  trajectory. 
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II.  MODELLING  BASICS 


A.  THE  GRID 

The  three-dimensional  database  that  is  created  in  DWB  is  initially  drawn  on  a 

2- dimensional  grid.  This  grid  can  be  positioned  or  oriented  anywhere  in  space  using 
the  mouse.  DWB  defaults  to  a  grid  with  an  XY  orientation,  with  a  standard  size 
and  units  (  either  metric  or  English  ).  These  values  can  be  changed,  but  whatever 
the  choice,  the  user  needs  to  be  consistent  with  the  grid  spacing  since  these  values 
become  important  during  the  linking  process. 

For  out-the-window  models,  it  is  recommended  that  the  user  change  the  orien¬ 
tation  of  the  grid  to  XZ,  since  this  also  helps  the  linking  process.  For  in-the- cockpit 
models,  the  grid  default  should  be  used.  For  more  discussion  on  the  grid  orientation, 
see  Chapter  IV. 

Most  of  the  editing  icons  used  for  constructing  a  model  are  self  explanatory. 
The  modelling  process  itself  is  not  complex,  but  it  is  very  time  consuming.  The 
models  constructed  for  all  the  animations  are  shown  in  the  Appendix.  Finally,  it 
is  very  important  that  the  user  be  aware  of  the  grid  orientation  during  any  editing 
operation  (  such  as  scaling,  translating  or  creating  a  polygon  ),  or  the  desired  effect 
will  not  be  achieved. 

B.  STRUCTURE 

DWB  provides  an  option  called  Z-buffering  which  gives  the  viewer  a  realistic 

3- dimensional  view  of  an  animation.  There  is  a  penalty  in  processing  time  and  not 
all  models,  such  as  a  static,  cockpit  need  it.  Here,  the  structure  of  the  model  becomes 
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Figure  2.1:  Structure  Page  for  Attitude  Indicator 

important.  DWB  automatically  generates  hierarchic  databases  composed  primarily 
of  groups  which  are  made  up  of  polygons. 

Grouping  your  model  is  important  for  a  number  of  reasons: 

•  Ease  of  editing 

•  Linking  in  Perspective  or  Clip  regions 

•  Drawing  Routines 

Editing  is  much  easier  if  objects  are  logically  grouped  and  the  groups  and  sub¬ 
groups  have  meaningful  names.  This  becomes  very  important  in  large  databases  with 
numerous  polygons. 

Logically  grouping  your  database  will  also  help  when  creating  links  after  the 
modelling  is  complete.  This  is  especially  important  in  Cli'p  or  Perspective  Regions, 
where  it  is  important  to  know  which  group  contains  the  elements  in  these  defined 
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areas.  It  is  also  easier  to  select  an  element  in  the  structure  page  by  its  name.  The 
drawing  routines  are  important  for  the  appearance  of  the  model.  DWB  automatically 
draws  the  polygons  and  strings  from  top  to  bottom  of  the  hierarchy  created.  This 
could  cause  an  element  to  be  blocked  by  another  drawn  above  it,  so  care  must  be 
taken  to  put  the  groups  in  the  correct  order.  Figure  2.1  shows  the  structure  page 
for  the  Attitude  indicator  model.  Here,  DWB  first  drew  the  backplate,  then  the 
ground/sky  background  on  top,  and  so  on  down  the  the  list.  A  correct  view  can 
easily  be  obtained  by  editing  with  the  Structure  icon  and  placing  the  groups  in  the 
order  needed.  Again,  structure  editing  is  important  for  objects  that  do  not  need 
Z-buflFering  to  preserve  the  correct  perspective. 

It  should  be  noted  that  the  background  and  climb/dive  groups  are  included 
within  the  ground/sky  group,  which  is  defined  as  a  Clip  Region  ,  described  in  the 
next  section. 

C.  REGIONS 

1.  Perspective  Region 

A  perspective  region  provides  for  an  out-the-window  view  of  an  animation. 
Once  the  boundaries  of  a  perspective  region  have  been  designated,  any  other  DWB 
file  can  be  imported.  Inside  the  perspective  region,  the  objects  and  eye-points  can 
move  however  the  user  desires,  while  outside,  the  perspective  remains  static.  It  is 
important  that  the  user  does  not  delete  the  separate  file  used  for  the  perspective 
region  once  it  is  imported.  The  parent  file  containing  the  perspective  region  does 
not  actually  save  the  file  within  the  region,  but  imports  it  whenever  initially  opened. 
This  means  that  changes  that  need  to  be  made  in  the  perspective  region,  must  be 
made  within  the  original  file. 
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To  generate  a  Perspective  Region: 


•  With  the  filename  designated  as  Parent,  create  a  new  group  (Click  on  NEW), 
and  then  designate  it  as  the  Parent. 

*  Note:  The  Parent  flag  tells  the  software  which  group  you  want  to  make 
changes  or  add  groups  to. 

•  Within  the  Edit  icon,  select  Modify  Attributes 

•  Click  on  Normal  and  select  Perspective  Region  then  Select  Reference  Points 

•  Follow  the  prompts  to  determine  boundaries  for  the  region  and  make  sure  to 
apply  the  changes 

•  Under  the  Structure  icon  ,  select  Create  and  Ext.  Page 

•  Select  the  file  that  will  be  imported  into  the  region 

It  should  be  noted  that  once  the  file  is  imported,  it  will  probably  not  be 
shown  with  the  correct  perspective.  Select  Modify  Attributes  again,  and  modify  the 
X,Y,Z  rotations  and  eyepoint  positions.  The  eyepoint  positions  must  be  at  (0,0,0) 
for  linking.  The  background  color.  Field  of  view  and  aspect  ratio  were  probably  also 
changed  and  can  also  be  modified  on  this  page  .  Any  other  modifications  must  be 
made  to  the  separate,  external  file  itself ,  not  while  it  is  included  as  an  import  file. 

2.  Clip  Region 

It  may  be  desired  that  a  model  contain  an  element  that  need  only  be  shown 
within  a  specified  area,  and  covered  up  outside  of  that  boundary.  The  airspeed  and 
altitude  tapes  were  two  such  elements  where  the  user  need  only  view  a  partial  segment 
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Figure  2.2:  Perspective  Region  Structure  and  Attribute  Page 

of  the  element.  Once  the  tapes  were  developed,  they  were  placed  in  another  group 
called  a  Clip  Region. 

To  create  a  Clip  region: 

•  The  elements  need  to  be  contained  in  a  separate  group. 

•  The  group  that  contains  the  element,  must  be  designated  the  Parent. 

•  Within  the  Edit  icon,  select  Modify  Attributes 

•  Click  on  Normal  and  select  Clip  Region  then  Select  Reference  Points 

DWB  will  then  give  a  prompt  to  choose  the  lower  left  and  upper  right 
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Figure  2.3:  Clip  Region  Structure  and  Attribute  Page 


boundaries  of  the  clip  region.  The  region  will  now  effectively  block  any  portion  of 
the  element  outside  the  defined  boundary,  and  if  the  element  translates  out  of  the 
defined  region,  it  will  disappear. 

Note  that  Altitude  is  selected  in  Figure  2.3  because  this  is  the  group  where 
the  Clip  region  is  defined  and  it  contains  within  it,  a  subgroup  where  the  actual 
altitude  tape  model  is  located. 


III.  FILE  FORMAT 


To  run  an  animation  in  DWB,  two  external  files  are  needed:  a  .data  file  and 
a  .vars  file.  The  data  file  drives  the  display  and  the  vars  or  variable  definition  file 
correlates  the  variable  in  the  data  file  with  those  in  the  linking  process. 

A.  .DATA  FILES 

The  data  file  that  drives  a  simulation  may  be  in  both  binary  and  ASCII  format. 
In  both  controllers  tested,  an  ASCII  file  generated  from  a  MATLAB  simulation  was 
used.  The  file  must  contain  51  columns  of  data,  but  can  be  of  any  length.  The  first 
column  must  contain  the  simulation  step  number  and  it  must  be  an  integer. 

Neither  of  the  data  files  used  was  originally  in  this  format,  and  had  to  be  mod¬ 
ified.  Step  numbers  were  added  in  sequence,  in  column  1  to  every  row  of  data  and 
zeros  were  added  to  increase  the  file  to  51  columns.  The  problem  of  the  first  column 
not  being  an  integer  still  remained.  This  was  corrected  by  using  a  program  called 
mat-dwb.exe  ,  on  the  Avionics’  Lab  PC,  America. 

To  Modify  the  data: 

•  Determine  the  length  of  the  .data  file 

•  On  PC  America:  cd  \  Borlandc  \  bin  then  aclOOsvr  to  allow  for  file  transfer. 

•  On  workstation:  ftp  america  then  put  (data  filename). data 

•  On  PC'.quit  to  end  file  transfer,  then  type  mat-dwb  to  start  the  conversion 
program. 


12 


Step 

F«d 

Lateral 

Vertical 

Roll 

Io(iex 

Velocity 

l/elociti) 

Velocity 

Rate  . 

1 

7.338e€l 

0.0006+00 

0.0006+00 

0.0006+00 

2 

2.3386401 

4.1136-10 

-7.3826-04 

1.9246-09 

3 

7.3306401 

5.4316-09 

-1.1316-03 

9.8706-09 

7.3306401 

2.2006-08 

-1.4006-03 

2.0036-08 

5 

7.3296401 

5.7836-08 

-1.6526-03 

2.8806-08 

6 

7.3296401 

1.1226-07 

-1.8956-03 

3.3806-08 

7 

7.3296401 

1.8246-07 

-2.0706-03 

3,3306-08 

8 

7.3206401 

2.0076-07 

-2.0926-03 

2.8226-08 

S 

7.3276401 

3.3776-07 

-1.8796-03 

1,9416-08 

18 

7.3276401 

4.0306-87 

-1.3736-03 

8,3116-09 

11 

7.3206401 

4,4706-07 

-5.4406-04 

-3.5056-09 

12 

7.3256401 

4.0516-07 

0.0926-04 

-1.4596-08 

13 

7.3256401 

4.5196-07 

2.0846-03 

-2.3776-08 

Figure  3.1:  Modified  .data  file 


•  Follow  the  prompts  then  type  aclOOsvr  again 


•  On  workstation,  you  may  have  to  close  then  open  the  ftp  utility  again  ,  and  get 
the  modified  data  file. 

*  Note:  Figure  3.1  shows  a  portion  of  the  data  file  after  it  has  been  modified. 
The  column  labels  do  not  appear  in  the  actual  file. 


B.  .VARS  FILES 


There  is  a  limit  to  the  number  and  type  of  variables  that  can  be  defined  in  a 
■  vars  file  if  using  an  ASCII  data  file,  but  these  should  more  than  enough  for  most 
simulations.  They  are: 

•  Floating  point  (  150) 
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1 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 

float 


u  (forward  velocity  ft/sec) 

V  (lateral  velocity  ft/sec) 
w  (vertical  velocity) 
p  (roll  rate  rad/sec) 
q  (pitch  rate  rad/sec) 
r  (uaw  rate  rad/sec) 
phi  (*57.3  deg-rad,  -90  to  +90) 

theta  (*57.3  deg-rad,  -90  to  +90)^^^ 
psi  f*57.3  deg-rad,  -90  to  +90) 

xjjos  eft) 

yjjos  (ft) 

Z  DOS  (ft) 

elevator  (rad  positive-pitch  down) 

rudder  (rad  positive-left  yaw) 

aileron  (rad  positive-right  roll) 

throttle  (unitless  1  is  A  hp) 

x_cnid  (ft) 

y  cmd  (ft) 

z  cmd  (ft) 

aTrspeed  (ft/sec-true) 

wind_x  (ft/sec) 

windjj  (ft/sec) 

wind_z  (ft/sec) 

x_err 

y_err 


Figure  3.2:  Corresponding  .vars  file 


•  Integers  (  50  ) 


•  Character  Strings  (  50  ) 

When  writing  a  file,  each  line  can  contain  only  one  variable  definition  and  must 
include  the  type  and  variable  name.  The  comments  that  are  m  parentheses  are 
optional.  The  .vars  file  corresponding  to  Figure  ??is  shown  in  Figure  3.2.  The 
position  of  the  variable  definition  within  the  file  is  extremely  important  as  it  directly 

relates  to  the  position  of  that  variable  in  the  data  file. 

During  the  linking  process,  DWB  may  not  list  the  variables  in  the  order  they 

were  written,  since  it  tries  to  put  them  in  alphabetical  order. 

The  easiest  way  to  create  a  new  .vars  file  is  to  just  copy  an  old  one  and  change 

the  variable  names  that  are  specific  to  the  new  data  file. 
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C.  .DRT  FILES 


These  files  are  used  in  the  Realtime  module  (RTM)  option  and  contain  a  com¬ 
bination  of  geometry  and  link  files  in  a  binary  format.  Animations  run  in  the  link 
editor  (LE),  emulate  those  run  in  RTM,  but  are  used  primarily  for  quick  and  easy 
verification  and  testing  of  the  dynamic  display.  RTM  animations  run  without  the 
editing  environment,  and  have  optimized  drawing  and  transformation  routines. 

Once  all  the  modelling  is  complete  and  the  links  have  been  defined  in  the  link 
editor,  the  file  can  be  saved  as  a  .drt  file.  An  RTM  animation  can  now  be  run  simply 
by  selecting  Run  RTM  under  the  Animation  icon. 
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Assignment  None  r- 


VisrSeigci 


Tavjnurfis  frame  number 


Qobal  Select  Help 

Mapping  For  top_tnnl'd't'selnicfc'showtime3,(lwbjinl!_op_2  | 

Function  linear  la'X+c]  j 

function  Values 

''-A  -! 

X  x_p«' 

I !  Constant  r  |"s'r 

1  Variable  j  Set 

! '  Mapped  r  |  sel" 

C  cos  [p75*psl+ {discrete)}*  1) 

IV.  LINKING 


A.  CREATION  OF  A  LINK 


The  linking  process  allows  the  user  to  take  a  data  file  and  map  specific  variables 
within  the  file  to  certain  elements  within  the  3-D  database,  and  use  this  mapping 
function  to  drive  the  animation.  To  create  a  link,  simply  select  the  desired  element 
within  your  database,  then  select  Create/Edit  on  the  Link  icon.  Next,  select  a 
mapping  function  and  variables  that  will  define  the  link. 

DWB  allows  for  numerous  functions  to  be  used  for  link  definition.  Figures 
4.1  through  4.3  show  how  more  complex  functions  can  be  created  by  nesting  the 
definitions.  By  selecting  mapped  instead  of  variable  within  the  Link  definition  page. 


Figure  4.1:  Nested  Link  1 


'-S': 


Mapping  For  C  coefliecient 


{a'eos^'c)] 


Function  cos 


Function  Values 


Constant  r  !  ^ei 


X  572 '‘psi+ (discrete) 


Corstanl  •“  Seti 


/^signment  Mone  r- 


ToVaiiaA- 


■WWWBBF 


Figure  4.2:  Nested  Link  2 


Mapping  For  X(variafale); 


Function  linear 


Function  Values 


Constant 


Variable  r^- 


Vef''  .c! 


toVara&te  ' 


V 

psi 

•  '  ' 

discrete 

-•  ' 

Figure  4.3:  Nested  Link  3 
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Figure  4.4:  Coordinate  Link 

that  one  ’’variable”  can  now  be  defined  as  an  entire  new  function. 

B.  TRANSLATION  LINKS 

As  with  all  links,  it  is  very  important  that  the  user  know  the  orientation  and 
size  of  the  grid  and  the  grid  spacing.  The  Translation  link  is  a  relatively  simple  one 
and  is  commonly  used  to  map  external  x  —  y  —  z  positions  from  a  data  file  to  the 
aircraft  model.  The  variables  that  define  the  motion  of  the  aircraft  or  element  to  be 
moved,  must  be  linked  to  the  proper  axis  on  the  defined  grid.  The  actual  value  of 
the  variable  will  be  used  to  translate  the  linked  object  that  same  number  of  units 
across  the  grid.  Measurement  units  such  as  ’feet’  or  ’em’  do  not  matter  as  long  as  it 
is  to  scale  and  all  files  are  consistent.  This  is  a  relative  translation,  and  it  is  based 
on  an  elements  relative  position  on  the  grid. 

Figure  4.4  shows  the  coordinate  link  used  to  move  the  UAV  model  within  the 


Item  Name 


b'nkOp.  Name 


translate 


Link  Type 


Input  Mapping 


1  ”  alt_eiT  +  0 


Mapped  To 


[  Lower  Mapped  Limit]  “1i 
[  Upper  Mapped  bmit]  16 


Translation  Link  Behavior: 


Translation  Vector 


Positive  Y  axis' 


[Tnoisjaipn  Offset]  -22 

,i,  .  ~77~ 


fl-L  .r 

f  '  ”  '  '  '  '  '  .  ■■  . . 

|j  Global  Select  Viev/ 

Help 

’  Link  Information 

Figure  4.5:  Link  for  Altitude  Error 


grid.  The  link  is  simply  three  translations  defined  at  once.  The  variables  xpos,  ypos 
and  zpos  are  from  the  MATLAB  simulation  data  and  are  used  to  define  the  aircraft 
position  on  the  grid.  Note  the  grid  axis  the  variables  are  mapped  to.  The  reason  for 
this  mapping  will  be  discusssed  in  the  Eyepoint  section. 

It  may  also  be  necessary  to  scale  a  translation  link  based,  for  example,  on  the 
size  of  the  display  versus  the  range  of  the  variable  used.  Figure  4.5  is  an  example  of 
how  to  define  limits  to  a  translation  link  using  the  instrument  modelled  for  displaying 
altitude  error  for  the  Altitude  Controller  simulation. 


#  The  altitude  error  was  determined  from  the  MATLAB  plots,  to  range  from  ± 
16  feet  (  from  Fig.  1.1  ) 

•  The  instrument  model  was  built  on  a  grid  with  XY  orientation,  so  the  indicator 
must  be  translated  up  and  down  the  positive  Y-axis. 
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Figure  4.6:  DWB  Rotation 

•  The  indicator  is  44  grid  units  high,  so  the  Translation  Distance  can  only  be 
44. 

•  The  range  of  motion  is  based  on  the  objects  initial  position.  A  Translation 
Offset  is  used  to  initially  place  the  indicator  at  the  minimum  value  which  is  22 
grid  units  down  the  Y-axis. 

C.  ROTATION  LINKS 

Once  again,  it  is  a  necessity  for  the  user  to  know  the  grid  orientation  used  for 
linking.  DWB  handles  angular  rotation  as  degrees.  The  Rotation  axis  is  based  on 
the  right  hand  rule  as  shown  in  Figure  4.6.  In  Figure  4.7,  roll  or  <;/»,  is  mapped  based 
on  the  defined  grid.  Translation  is  in  the  negative  Z  direction  and  roll  would  about 
the  DWB  defined  positive  XY  axis,  or  the  Z-axis.  Values  for  pitch  and  heading  were 
similarly  mapped. 
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Figure  4.7:  Rotation  Link  for  Attitude  Indicator 
D.  EYE  POINTS 

Eyepoint  links  are  used  to  follow  a  specific  element,  like  an  aircraft,  during 
an  animation.  DWB  uses  the  axis  system  shown  in  Figure  4.8  for  the  eyepoint 
perspective  and  for  eyepoint  link  definitions.  When  defining  the  link,  if  an  object  or 
eyepoint  is  to  move  left  and  right  on  the  screen,  the  variable  defining  that  motion 
must  be  mapped  to  the  X-axis.  An  object  moving  into  the  screen  must  be  mapped 
to  the  Z-axis  and  the  Y-axis  is  used  for  motion  up  or  down  the  screen.  This  is  why 
it  is  easier  to  model  out-the-window  scenes  on  a  grid  with  an  XZ  orientation.  When 
an  AF  orientation  is  selected  with  the  edit  icons,  DWB  automatically  puts  the  user 
looking  directly  down  the  negative  Z  axis  (  The  default  eyepoint  axis  ).  If  the  model 
was  drawn  with  another  initial  orientation,  the  translations  necessary  to  look  down 
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y-i)cis 


Figure  4.8:  DWB  Eyepoint  Perspective 

the  Z  axis  would  not  be  exact,  and  the  eyepoint  links  would  probably  not  work! 

The  eyepoint  links  are  also  a  relative  motion  link.  The  initial  eyepoint  position 
defaults  to  the  (0,0,0)  coordinate  of  the  grid  when  an  animation  is  begun.  The  motion 
of  the  eyepoint  link  is  based  on  grid  size  but  not  on  the  grid  orientation.  Again,  the 
direction  of  motion  is  based  on  the  axis  in  Figure  4.8. 

When  creating  an  eyepoint  link,  the  filename  or  page  in  the  perspective  region 
must  be  selected  and  then  Create/Edit  selected  under  the  Link  icon.  Eye-point 
position  or  rotation  must  then  be  selected. 

1.  Tail- following  Eyepoint 

To  achieve  an  eyepoint  that  would  follow  an  aircraft  throughout  the  simu¬ 
lation,  simple  geometry  was  used.  The  example  in  Figure  4.9  shows  how  the  links 
for  the  position  controller  were  defined.  First,  an  arbitrary  distance  for  the  eyepoint 
to  remain  behind  the  plane,  D  ,  must  be  chosen.  The  variables  xpos  and  ypos  were 
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D 


I  +EYE1 

Figure  4.9:  Tail-following  Geometry 

defined  in  the  simulation  to  govern  the  motion  of  the  plane  in  an  XY-plane.  Again, 
for  an  eyepoint  when  viewing  the  animation,  this  plane  of  motion  becomes  XZ  !  As 
the  aircraft  model  moves  from  POSl  to  POS2  ,  the  eyepoint  must  move  from  EYEl 
to  EYE2  to  remain  at  the  chosen  distance  behind  the  model  and  maintain  that  ’’tail¬ 
following”  perspective.  So,  as  the  model  moves  xpos  units  on  the  negative  Z-axis 
and  ypos  units  on  the  positive  X-axis,  it  is  easy  to  see  that  the  eyepoint  position  is 
governed  by  the  following  equations: 

•  EyeZ  =  —xpos  {D  *  costj}) 

•  EyeX  =  ypos  —  {D  *  sintp) 
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Figure  4.10:  Interactive  View  Choice  Buttons 


2.  Interactive  Eyepoints 

It  may  be  desired  to  have  a  number  of  different  eyepoints  defined  that 
the  user  can  choose  interactively  while  the  animation  is  running.  For  each  of  the 
View  Choice  buttons  in  the  position  controller  simulations,  shown  in  figure  4.10,  a 
Momentary  Control  link  was  defined.  When  the  user  selects  a  particular  view  with 
the  mouse,  a  discrete  value  of  either  0,1,2  or  3  is  generated.  The  user  defines  these 
discrete  values  within  the  link. 

These  values  are  then  used  in  the  eyepoint  position  and  rotation  links  where 
they  were  defined  to  correspond  to  certain  angles.  These  angles  were  added  to  the 
heading  rotation  angle, ^  ,  and  in  this  way  positioned  the  eyepiece  for  the  desired 
perspective. 

The  discrete  definitions,  corresponding  angle  changes  and  resulting  views 
are  shown  below: 


24 


Discrete 

Value 

Angle 

Change 

View 

0 

0 

Rear 

1 

90 

Left  Wing 

2 

180 

Front 

3 

270 

Right  Wing 

Figures  4.11  through  4.13  show  the  actual  Momentary  Link  for  the  Rear 
view  button  and  how  they  were  integrated  within  the  eyepoint  links.  When  creating 
the  momentary  link,  select  discrete  as  the  function  to  produce  the  box  on  the  left  of 
figure  4.11.  When  Define  is  selected,  the  right  figure  appears,  allowing  the  user  to 
input  any  desired  values,  in  this  case,  zeros. 

Figure  4.12  shows  where  the  discrete  mapping  would  be  added  to  the  actual 
eyepoint  link.  The  values  now  used  for  these  discrete  mappings  are  shown  in  figure 
4.13,  and  are  added  to  the  heading  angle. 

Figure  4.14  shows  the  slightly  different  mappings  used  for  the  Altitude  Con¬ 
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Figure  4.12:  Tail-follow  Eyepoint  with  Discrete  Definitions 
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Figure  4.13:  Discrete  Value  Mappings  for  Angle  Change 
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Figure  4.14:  Discrete  Mappings  for  Altitude  Controller 
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V.  ANIMATIONS 


A.  LINK  EDITOR 

While  animations  run  in  the  Link  Editor  are  not  done  in  an  optimum  way,  they 
do  allow  for  quick  verification  and  testing.  To  begin  an  animation,  the  following  files 
must  be  loaded: 

•  The  .Ink  file  created  for  dynamic  behavior. 

•  The  .vars  file,  found  under  Load  Sim  Names  within  the  Links  icon. 

•  The  .data  file,  found  under  Configure  Comms  within  the  Animation  icon. 

Select  Data  File  under  Methods  of  Comm  . 

Enter  desired  file. 

Note  :  Once  the  .data  file  is  entered  in  Configure  Comms  window,  all  the 
necessary  files  can  be  saved  as  a  .cco  file.  The  Link  Auto  Load  function  can  then 
automatically  load  the  .vars  ,  .Ink  and  .data  files.  This  option  is  available  if  the 
user  desires,  whenever  the  modeled  is  subsequently  loaded.  All  the  files  must  have 
the  same  name  as  the  model  file.  The  animation  can  then  be  started  once  the 
loading  is  complete. 

B.  REALTIME  MODULE 

Once  the  editing  for  an  animation  is  complete,  an  optimum  animation  can  be 
generated  using  the  Realtime  Module  (  RTM  ).  The  RTM  manager  processes  the 
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animation  at  a  faster  rate  and  optimizes  certain  functions,  like  z-buffering,  to  improve 
the  realtime  performance. 

To  generate  an  RTM  animation, 

•  The  file  must  first  be  saved  an  a  .drt  file. 

•  Select  Configure  Display  ,  under  the  Animation  icon,  and  select  desired  options. 
Most  likely,  Z-buffer  ON  or  SELECTIVE. 

•  Select  Run  RTM  . 

The  animation  will  now  take  up  the  entire  screen,  eliminating  the  Link  Editor 
environment.  The  esc  key  can  be  used  to  return  to  the  editing  environment. 

1.  Performance 

Actual  realtime  performance  of  the  animation  is  not  guaranteed  with  DWB 
and  is  highly  hardware  and  software  dependent.  Optimal  development  of  the  database 
can  improve  simulation  time  by  allowing  the  RTM  drawing  routines  to  operate  more 
efficiently.  A  few  examples  of  how  to  improve  DWB  performance  are: 

•  Use  Selective  Z-buffering.  DWB  then  only  processes  those  elements  that  have 
the  flag  set  on  the  attributes  page.  Elements  such  as  cockpit  instruments  where 
only  one  view  is  needed  would  not  have  this  flag  set. 

Note  :  Z-buffer  flashing  is  caused  by  elements  that  are  constructed  on  the  same 
plane  on  top  of  one  another,  such  as  a  runway  over  the  airfield.  DWB  cannot 
decide  which  perspective  is  correct.  It  alternates  priorities  as  the  perspective 
changes,  producing  a  flashing  effect.  This  can  easily  be  avoided  by  translating 
each  element  slightly  off  the  original  plane  ,  each  at  different  distances. 
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•  Use  the  minimum  number  of  polygons  to  create  a  model.  DWB  must  update 
all  polygons  each  time  the  scene  is  updated. 

•  Use  flat  illumination.  This  is  processed  the  fastest  even  though  it  may  not 
provide  the  most  realistic  image. 

The  NFS  Avionics  Lab  currently  ha.s  relatively  fast  graphics  processors.  The 
greatest  contributor  to  long  simulation  time  is  the  length  of  the  data  file  being  used. 
Trial  and  error  has  shown  that  ten  to  fifteen  lines  of  data  per  second  of  simulation 
produce  real-time  animations  within  the  link  editor,  and  slightly  faster  during  RTM, 
without  losing  much  quality  in  the  animation  itself. 


30 


VI.  CONCLUSIONS 


With  its  many  capabilities,  DWB  provides  another  valuable  analytical  tool  for 
Control  System  Designers.  While  unable  to  provide  a  detailed  analysis  of  the  design 
performance,  it  can  provide  limited,  but  important  feedback  to  the  designer  in  the 
more  intuitive  graphical  environment.  With  the  capability  to  read  data  over  the 
Ethernet,  future  use  for  DWB  will  be  to  provide  real-time  feedback  for  ’’Hardware- 
in-the-loop”  simulations  for  the  UAV  project  at  NFS,  and  eventually  be  used  for 
tethered  or  wireless  flight  testing. 
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APPENDIX  A 

MODELS  CREATED  WITH  DWB 
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Figure  A.l:  Designer’s  Workbench  Link  Editor  Environment 
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Figure  A. 3:  Generic  Jet  Aircraft 
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Figure  A. 6:  Trajectory  Controller  :  Aircraft  Initial  Position  on  Airfield 
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